I also noticed that on the edge server, there is a usb adapter in the interface list, which is always shown as LOWER_UP. Therefore, if there is at least one lower_up, then we proceed to configure the l3 network which does not work in this case.

I'm still curious, I gathter you want to wait up to 20 seconds for link to negotiate, but does it really have to be one at a time? In this scenario I'd wonder if the original 'link up all the nics at once' behavior is still sufficient, but with a loop to loop the nic iteration:
diff --git a/confluent_osdeploy/ubuntu22.04/initramfs/scripts/init-premount/confluent b/confluent_osdeploy/ubuntu22.04/initramfs/scripts/init-premount/confluent
index 03761f3a..8beb805e 100755

--- a/confluent_osdeploy/ubuntu22.04/initramfs/scripts/init-premount/confluent
+++ b/confluent_osdeploy/ubuntu22.04/initramfs/scripts/init-premount/confluent
@@ -31,6 +31,7 @@ if [ -e /dev/disk/by-label/CNFLNT_IDNT ]; then
             MYGW=""
         fi
         MYNM=$(grep ^ipv4_netmask: $tcfg | awk '{print $2}')
+        while [ -z "$NIC" ]; do
             for NICGUESS in $(ip link|grep LOWER_UP|grep -v LOOPBACK|cut -d ' ' -f 2 | sed -e 's/:$//'); do
                 ip addr add dev $NICGUESS $v4addr
                 if [ ! -z "$MYGW" ]; then
@@ -49,6 +50,7 @@ if [ -e /dev/disk/by-label/CNFLNT_IDNT ]; then
                     break
                 fi
             done
+        done
         ipconfig -d $MYIP::$MYGW:$MYNM::$NIC
         echo $NIC > /tmp/autodetectnic
     else

As i mention, even if we have link up for all nics at before, we also need wait a servel times until their up. it not up immediately
If we use "IP link | grep LOWER_UP | grep -v LOOPBACK | the cut - d '- f 2 | sed -e' s / : $/ / '" to filter all of the available network card, we will not get the real card, Since it has a usb network card in the interface list and LOWER_UP always appears, so i have to be one at a time.

The more explicit way to do this is probably by filtering out any netdevs using the loopback or cdc_ether (and friends) drivers by checking /sys/class/net/$iface/device/driver, and waiting for link up on anything left. Unless you expect to actually ever use the USB nic for regular network traffic of course. I'm not familiar with these specific platforms but typically the USB nic is for inband BMC access as an alternative to ipmi via the Redfish HostInterface or equivalent.

On the matter of the one at a time, my hope was that the addition of the outer 'while' loop would address that issue, along with a few others. The problem as I saw was that there's only a single loop going through the interfaces. Problems that can happen to be aware of:
-Slow link up time
-Fast link up, but slow forwarding (e.g. spanning tree). In this case 20 seconds is not going to be enough
-An interface gets enumerated but is not viable for the specified network configuration (either gets enumerated first or has link first.
-Bonus, as referenced, the redfish host interface is a waste of time to consider, so it'd be nice to skip, as Ryan noted there could be a better way to do that. Fortunately, we have a somewhat better way to identify redfish host interface:

# dmidecode -t 42
Handle 0x0082, DMI type 42, 169 bytes
Management Controller Host Interface
        Host Interface Type: Network
        Device Type: USB
        idVendor: 0x04b3
        idProduct: 0x4010

Unfortunately this function may need to be fleshed out over time, since there are multiple ways for the record to indicate the NIC. For now, all my platforms gives us the usb vender and product id, and that can be used.

Since the existing for loop, in theory, should not be satisfied by mere 'link up' already, I was hoping that repeating the loop until a pass identifies a NIC it would get to the end game, and do so in a manner robust against all the scenarios.

I am wondering if:
2c9b526

Solves this.

It does not do anything with the host interface (no parsed DMI handy nor utility to parse it), but the impact is still hopefully mitigated by the repeat loop.